Florian Müllner [Wed, 2 Aug 2023 16:09:46 +0000 (18:09 +0200)]
status/backlight: Notify slider value changes
The custom setter used by the slider item isn't emitting change
notifications, so the property binding that uses it as source
never propagates the new value.
We have always defaults to an empty ornament, so that menu items
are always aligned, even when radio items are used.
However radio items are fairly rare, so most of the time we end
up with an extra margin with no purpose. The design team now
prefers radio items to only align with each other, so that regular
items get the expected margin.
We currently consider idle nodes as in use to avoid too fast state
changes and thus flickering of the indicator icon. However, the current
idle timeout is rather long and arguably confusing for users.
Thus switch to only consider running nodes as in use, but delay
disabling of the indicator by 500ms.
Florian Müllner [Tue, 13 Jun 2023 19:36:20 +0000 (21:36 +0200)]
status/backlight: Add new quick toggle
Settings no longer exposes a slider for the keyboard brightness,
leaving keyboard shortcuts as the only way of adjusting it.
This is good enough in most cases, because devices with keyboard
backlight usually include corresponding keys on their keyboard.
However for devices without those keys, it would be good for the
settings to be exposed somewhere again. Quick settings seems like
a more appropriate place than "proper" Settings, since it gives
quick access that doesn't require a major focus change.
extensions: Make ExtensionPreferences more flexible
Extensions must now export a class with a fillPreferencesWindow()
method in their prefs. That is less convenient for extensions
with simple preferences than the old buildPrefsWidget() hook, as
they must wrap their widget in page/group widgets.
Address this by adding a default fillPreferencesWindow() implementation
that calls a getPreferencesWidget() method and wraps it as necessary.
This is flexible enough to support different cases fairly conveniently,
from simple single-widget prefs over tweaking the window to complex
multi-page prefs:
```js
class SimplePreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
}
class TinkerPreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
If an extension provides the gettext domain in its metadata,
then we can simply set up translations from the constructor,
so do that for a bit more convenience.
All extension lookups now happen through the dedicated
Extension/ExtensionPreferences classes, so the shared
code no longer has to access the extensionManager.
Use the new defineTranslationFunctions() method from the previous
commit to create gettext functions for the module, instead of
re-exporting from the shared module.
It is now up to extension developers to use the more effective
The method can be used to define a set of gettext functions that
call the corresponding method of an extension.
Those functions are very similar to the gettext functions we are
exporting, except that:
- looking up the extension is delegated to the
Extension/Preferences class
- it is possible to avoid examining the stack
when called with `import.meta.url`
With convenience API like getSettings() now being provided by
the ExtensionObject subclass, extensions will need to access
their entry point more often.
Having to pass a pointer through the hierarchy can be annoying,
so add a static method that allows them to look it up:
extension-tool: Use Extension base class in templates
The Extension/Preferences classes are where we will focus for
future extension convenience API, so developers should be
encouraged to use them as entry points.
extensions: Add Extension/Preferences base classes
Extensions now must export a class that conforms to a particular
interface both for the actual extension as well as for prefs:
enable()/disable() methods for the former, fillPreferencesWindow()
for the latter.
This is quite similar to the previous method-based entry points,
but it also gives us a more structured way of providing convenience
API in form of base classes.
Do that in form of Extension and ExtensionPreferences classes on
top of a common ExtensionBase base class.
getSettings(), initTranslations() and the gettext wrappers are
now methods of the common base, while openPreferences() moves
to the Extension class.
extensionSystem: Include dir and path in data passed to extension
Extensions often need to set up additional resources from their
directory, like settings, translations or image assets.
So far extensions have used getCurrentExtension() to access the
shell's internal extension object which contains path and dir
properties. That's far from ideal, first because it requires
generating a stack to figure out the current extension, and
second because the internal object also contains state that
extensions shouldn't meddle with.
Just include those properties in the metadata we pass to the
extension constructor.
Pipewire allows us to easily track whether any cameras are in used by
checking the state of camera nodes. Add a simple camera monitor to the
shell, allowing us to show e.g. a status indicator.
Naturally the monitor is limited to apps using Pipewire for camera
access and thus subject to the same chicken-egg problem like the camera
portal - it could confuse users that apps may use the camera without
being noticed by the monitor. The hope and assumption here is that a
better shell integration might speed up adoption of the new camera APIs
Pipewire 0.3.49 is required for refcounted `pw_init()`/`pw_deinit()`.
The Config variable that was removed in the previous commit was
actually wrong (PACKAGE_VERSION vs. GETTEXT_VERSION), so the
substituation didn't work.
Meson warns about this, let's make these warnings fatal to catch
similar issues during CI.
extensions: Unify how manager is injected into shared module
We unified most code paths earlier, but the common code will still
import Main locally if no extension manager was injected before.
Now that the old extensionUtils was split between extension and
preferences, each of those modules can simply import the manager
from its corresponding environment, and then inject it into the
shared module.
The module is now only used inside the gnome-shell process, so
we don't have to handle the case where it is used from prefs,
and we can use regular imports for shell modules.
For the time being this mostly means re-exporting functions
from the shared module. However openPrefs() is now only
available to extensions, and we stop exporting both
getCurrentExtension() and setExtensionManager() to either
extensions or prefs.
We got rid of all uses of extension utils code in the gnome-shell
process itself, and everything that is now using it - including
extensions - is already loaded as module.
We can therefore quickly move the file to ESM, which will help
a bit with upcoming changes.
Florian Müllner [Fri, 30 Jun 2023 10:57:41 +0000 (12:57 +0200)]
extensionUtils: Split out extension convenience functions
ExtensionUtils was originally used for shared functions between
the extension system and the (old) prefs-tool, but then gained
useful API meant for extensions themselves.
It's a bit weird to mix the two, so split out the extension convenience
API into a separate module.
We will soon split up the module further, and add specific "flavors"
for extensions and preferences, with the current code providing a
shared base for both.
That should explain both the new location and the odd module name. :-)
ExtensionUtils' getCurrentExtension() method currently either
returns the extension that was injected with setCurrentExtension(),
or imports Main locally to access the extensionManager.
But local imports won't work anymore when we convert to ESM,
and setCurrentExtension() is only an option for prefs.
Instead of diverging the code paths even further, we'll unify
the two cases as much as possible.
As a first step, add a basic extension manager in the Extensions
D-Bus service that exposes the same lookup() API as the "real"
extension manager.
dbusServices/extensions: Save stateObj on extension
We don't need it for anything for the time being, but reducing the
differences between extension object in the gnome-shell process and
in preferences still seems a good idea.
dbusServices/extensions: Don't use getCurrentExtension()
The prefs dialog is created on behalf of a particular extension.
It's a bit silly to rely on getCurrentExtension() to access it,
instead of just keeping track of it ourselves.
extensionUtils: Slightly optimize current extension lookup
When looking for a directory name that matches the extension UUID,
we can just as well use GLib's dirname()/basename() functions
instead of wrapping the path in a GFile.
We also know that the original path corresponds to a regular file
and not a directory, so rearrange the loop to avoid a lookup that
is guaranteed to fail.
extensionUtils: Stop using RegExp for stack parsing
We currently use a regular expression to extract the exact file path
from a stack line. That RE is no longer accurate:
- we assume a line number at the end, but at one point the column
number was added as well
- stacks from ES modules use file:// URIs instead of plain paths
Luckily that doesn't matter: We don't want to access any actual
files, so all we need is a path that can be traversed and that
contains the UUID.
We can get that with simple string manipulation, so avoid the regex
overhead.
Required dependencies are always imported, compile-time optional
dependencies
are loaded if gnome-shell is compiled with support for them, and for
runtime optional dependencies we catch any errors when attempting to
load them.
If runtime optional dependencies fail to load we log a debug-level
message.
We started to version them last cycle, so docs can be differentiated
between versions. It is not *expected* that two versions show up
on the same system, but then it also doesn't hurt handling it.
animationUtils: Group together various animation helpers
The environment module is used to initialize the environment, yet it
currently also defines the adjustAnimationTime() function.
Ideally it should not export any utility functions, in particular
once converted to ESM.
The function cannot be moved to the existing Utils module, as that
depends on an initialized environment, and can therefore not be
imported from environment.js, so use that opportunity to group
together several animation helpers in a new animationUtils module.
Part of the possible completions involves evaluating the part
of the passed in text that looks like an object, so that we
can query it for properties.
Using a Function or eval() for that means that we can only
complete text that does not use `await`. To get over that
limitation, evaluate the text in an AsyncFunction instead.
We currently throw an error when encountering a result that cannot
be represented as string, with the prompt appearing somewhat stuck
(the input cannot be committed).
Showing a lame fallback instead at least avoids that issue. When
the object has a typeof 'object' but is not an instanceof Object,
we are likely dealing with an ES module, and can show a slightly
less lame fallback.
projects / gnome-shell.git / log